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DETAILED ACTION 

1 . This Action is in response to Amendment filed 12/3/04, which has been fully considered. 

2. Amended claims 1-18 and new claims 21 and 22 are presented for examination. 

3. Claims 19 and 20 are cancelled by Applicant. 

4. This Action is FINAL. 

Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

Claims 1, 3-18 and 21 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Wang et al. (US 5,9 13,028) (hereinafter Wang) in view of Stevens ("TCP/IP Illustrated, 
Volume 1 : The protocols," New York, 1994.) and further in view of Schulzrinne et al. (RFC 
1889, http://vv^.ietf.org/rfc/rfcl889.txt?number=1889, Januaryl996) (hereinafter 
Schulzrinne). 

As for claims 1 and 21, Wang discloses an apparatus for transferring information between 
a network and a storage device, the apparatus comprising: 

a host computer having a CPU (CPU 24, Fig. 2) operating a file system (file system 27, 
direct file system 28, and peer I/O manager 26, Fig. 3) and a host memory (memory 32, Fig. 
2) connected to said CPU by a host bus (Figs. 2 and 3), and 



/ 
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an interface device coupled to said host computer, to the network and to the storage 
device, said interface device including an interface memory containing an interface file cache 
(local memory 44, Fig. 3) adapted to store data that is communicated between the network 
and the storage device under control of said file system (Network I/O Device, Fig. 3; col. 3, 
lines 31-52; col. 4, line 50 - col. 5, line 5), 

wherein said host computer is configured to designate a socket that is accessible by said 
interface device, and said interface device is configured to communicate said data between 
the network and the file cache according to said socket (Note, a socket is merely a destination 
address and port, which is required for data transfer on a network. See cited definition from 
techdictionary.com.; col. 4, line 38 - col. 5, line 5; Fig. 3). 

Although obvious to one of ordinary skill in the art at the time of the invention, Wang 
does not explicitly teach that the socket may be User Datagram Protocol (UDP) socket. The 
Examiner notes that UDP is a well-known protocol for data transfer on networks, as shown 
by Stevens, Chapter 1 1, for example. Schulzrinne further teaches the use of UDP as an 
underlying protocol for RTP in order to maintain the real-time characteristics of data such as 
audio and video (section 1, Introduction). As understood by one of ordinary skill in the art at 
the time of the invention, when UDP is used, UDP sockets are inherently required in order to 
receive the information packets over the network (see cited definition from 
techdictionary.com). It would have been obvious to one of ordinary skill in the art at the 
time of the invention to modify the teachings of Wang by using UDP sockets in order to 
maintain the real-time characteristics of data such as audio and video, as taught by 
Schulzrinne above. 
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8. As for claim 3, Wang does not explicitly disclose the use of Realtime Transport Protocol 
(RTP) headers. Schulzrinne teaches creating RTP headers and prepending the header to the 
data for transmission over the network (Sections 5, 5.1, 10). It would have been obvious to 
one of ordinary skill in the art at the time of the invention to modify Wang by creating RTP 
headers and prepending the header to data in order to maintain the real-time characteristics of 
data such as audio and video, as taught by Schulzrinne above. 

9. As for claims 4, 5 and 6, Wang does not explicitly disclose the use of UDP headers. 
Stevens teaches that UDP, by definition, prepends data with UDP headers, wherein the data 
is further divided into plural fragments which are concatenated corresponding to the UDP 
header (Sections 1 1 .2 and 1 1 .5). It would have been obvious to one of ordinary skill in the 
art to modify Wang by using UDP headers and dividing the data into plural fragments, in 
order to efficiently transfer data over a network, as taught by Stevens above. 

10. As for claim 7, Wang teaches the apparatus of claim 1, wherein said data does not enter 
said host computer (col. 3, lines 31-52; Fig. 3). 

11. As for claims 8 and 9, Wang does not explicitly teach that the data may comprise audio 
and video data. Schulzrinne teaches the transfer of audio and video data over a network 
(Section 1, Introduction). It would have been obvious to one of ordinary skill in the art at the 
time of the invention to modify Wang by transferring audio and video data in order to make 
this data accessible over a network. 

12. As for claim 10 , Wang teaches the apparatus of claim 1, wherein said data is a part of a 
realtime communication (col. 3, lines 31-52). 
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13. As for claim 11, Wang discloses an apparatus for transferring information between a 
network and a peripheral device, the apparatus comprising: 

a host computer having a processor(CPU 24, Fig. 2) connected to a host memory 
(memory 32, Fig. 2) by a host memory bus (connection illustrated in Fig. 2), said host 
memory containing an application operable by the processor to designate a socket (Note, a 
socket is merely a destination address and port, which is required for data transfer on a 
network. See cited definition from techdictionary.com.; col. 4, line 38 - col. 5, line 5; Fig. 
3), and 

an interface device (network I/O device 40, Fig. 2) connected to said host computer and 
coupled between the network and the peripheral device, said interface device including an 
interface memory adapted to store data corresponding to said socket and a mechanism 
configured to associate said data with a header corresponding to said socket such that said 
data is communicated between the network and the peripheral device without encountering 
said host computer (col. 4, line 38 - col. 5, line 5; Fig. 3). 

Although obvious to one of ordinary skill in the art at the time of the invention, Wang 
does not explicitly teach that the socket and header may be a User Datagram Protocol (UDP) 
socket and header. The Examiner notes that UDP is a well-known protocol for data transfer 
on networks, as taught by Stevens, Chapter 1 1, for example. Schulzrinne further teaches the 
use of UDP as an underlying protocol for RTP in order to maintain the real-time 
characteristics of data such as audio and video (section 1, Introduction). As understood by 
one of ordinary skill in the art at the time of the invention, when UDP is used, UDP sockets 
are inherently required in order to receive the information packets over the network (see cited 
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definition from techdictionary.com). Similarly, UDP headers are inherently required for 
addressing each of the packets (see Stevens, section 1 1 .2). It would have been obvious to 
one of ordinary skill in the art at the time of the invention to modify the teachings of Wang 
by using UDP sockets and headers in order to maintain the real-time characteristics of data 
such as audio and video, as taught by Schulzrinne above. 

14. As for claim 12, Wang discloses the apparatus of claim 11, wherein said host computer 
contains a file system (file system 27, Fig. 3) and said interface memory includes a file cache 
(local memory, 44, Fig. 3) adapted to store said data, wherein said file system manages 
storage of said data in said file cache (col. 4, line 38 - col. 5, line 5; Fig. 3). 

15. As for claims 13 and 14, Wang does not explicitly disclose the use of UDP packets and 
headers. Stevens teaches that UDP, by definition, includes UDP packets and headers, 
wherein said data travels over the network in plural fragments (packets) corresponding to the 
header. The interface device is further required to process the UDP headers and concatenate 
the data. See Stevens, Chapter 1 1, especially Sections 1 1 .2 and 1 1 .5. It would have been 
obvious to one of ordinary skill in the art at the time of the invention to modify Wang by 
using UDP packets and headers, wherein the interface device processes the headers and, 
concatenates the data, because these are well-known and necessary steps in order to 
efficiently transfer data over a network, as taught by Stevens above. 

16. As for claim 15, Wang does not specifically disclose the use of Realtime Transport 
Protocol (RTP). Schulzrinne teaches the use of RTP and RTP headers in order to transfer 
data over a network while maintaining the real-time characteristics (Section 1, Introduction; 
Section 5. 1 , RTP Fixed Header Fields). It would have been obvious to one of ordinary skill 
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in the art at the time of the invention to modify Wang by using RTP and RTP headers in 
order to transfer data over a network while maintaining the real-time characteristics, as taught 
by Schulzrinne above. 

1 7. As for claims 1 6 and 1 7, Wang does not explicitly teach that the data may comprise audio 
and video data. Schulzrinne teaches the transfer of audio and video data over a network 
(Section 1, Introduction). It would have been obvious to one of ordinary skill in the art at the 
time of the invention to modify Wang by transferring audio and video data in order to make 
this data accessible over a network. 

18. As for claim 18, Wang teaches the apparatus of claim 1 1 , wherein said data is a part of a 
realtime communication over the network (col. 3, lines 31-52). 

19. Claims 2 and 22 are rejected under 35 U.S.C. 103(a) as being unpatentable over Wang in 
view of Stevens and Schulzrinne and further in view of Applicant's admitted prior art (pg. 
31, line 28 - pg. 32, line 8) (hereinafter AAPA). 

As for claims 2 and 22, Wang explicitly teaches the use of application layer headers, 
which inherently includes prepending these headers to the data (col. 11, lines 14-36), because 
otherwise the data packets could not be transferred. It is not clear from Wang whether or not 
these application layer headers are created by the host computer or the interface device. 
Thus, Wang, Stevens, and Schulzrinne do not specifically disclose that the host computer is 
configured to create the application layer header that is accessible by said interface device. 
However, AAPA (pg. 31, line 28 - pg. 32, line 8) teaches that it is conventionally known to 
generate an application packet header at a host computer. Therefore, it would have been 
obvious to one of ordinary skill in the art at the time of the invention to modify the teachings 
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of Wang and Schulzrinne by configuring the host computer to create an application layer 
header that is accessible by said interface device in order to transmit application data over the 
network. Moreover, it would have been obvious to generate the application headers at the 
host computer of Wang, because the application resides on the host computer and this would 
simplify data processing. 

Response to Arguments 

112 Claim Rejections 

20. The rejection of claims 7 and 11-18 under 35 U.S.C. 1 12, second paragraph, is hereby 
withdrawn. In particular, the Examiner finds that the claims are not indefinite when taken in 
context of the specification (for example, Fig. 1 clearly illustrates a host computer 20). 

Double Patenting 

21. The obvious-type double patenting rejection of claims 1-18 is hereby withdrawn after 
further consideration and in view of Applicant's Remarks on pgs. 12-13. 

103 Claim Rejections 

22. Applicant's arguments filed 12/3/04 have been fully considered but they are not 
persuasive. 

On pages 15-17 of the Remarks, Applicant asserts that Wang fails to teach an "interface 
file cache." The Examiner respectfully disagrees. First, the Examiner notes that the term 
"interface file cache" does not have a standard meaning in the art. Applicant has further not 
explicitly defined the term in the specification. Therefore, any cache (i.e. temporary 
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memory) performing the functions claimed is sufficient to anticipate an "interface file 

cache." As noted in the cited definition from techdictionary.com, a cache is "a temporary 

memory area for frequently-accessed or recently-accessed data." The local memory 44, Fig. 

3 (also local data buffers 44, Fig. 5) of Wang provides just such temporary storage for files 

transferred on the network. As explicitly noted in col. 4, lines 55-58, of Wang: 

The storage I/O device reads data into its local memory and then moves the 
data directly into buffers on the network I/O device. 

See also col. 5, line 56 - col. 6, line 7. With reference to the passages cited by Applicant, the 

Examiner finds that the "peer I/O manager" of Wang is part of the overall "file system" (see 

col. 11, lines 24-36). Thus, Wang also anticipates the limitation that the transfer occurs 

"under control of said file system." Therefore, the Examiner properly interprets that the local 

memory 44 of Fig. 3 is an "interface file cache." 

On pages 17 and 18 of the Remarks, Applicant further asserts that the Examiner has 

failed to provide proper motivation for the combination of the references because "there is no 

existing protocol standard that implements UDP over IPX." The Examiner respectfully 

disagrees. First, the Examiner finds that the real issue at hand is not whether or not there 

exists a protocol standard that implements UDP over IPX. The question is what would be 

suggested as a whole to one of ordinary skill in the art by taking the combined teachings of 

the references. The Examiner concedes that Wang uses the IPX network protocol. 

However, the TCP/IP protocols are commonly known to those of ordinary skill in the art; 

and, it is also well-known that one protocol may be substituted for another depending on the 

particular application or network requirements. As noted in RFC 1889, UDP has the 

advantage of being an underlying protocol for RTP, which provides for the real-time 
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transmission of audio and video data. Thus, it would have been obvious to one or ordinary 
skill in the art to modify Wang by using EP network protocols instead of IPX, if necessary. 

Moreover, the Examiner finds that RFC 1791 would have been sufficient to teach the 
implementation of UDP over IPX to one of ordinary skill in the art, since this was 
specifically contemplated and detailed in the RFC which dates back to 1995. Applicant's 
statements that this would be too "risky" for one of ordinary skill in the art are merely 
conjecture without any factual basis. Thus, whether or not Wang was modified to use an IP 
network protocol, it would have been obvious to one of ordinary skill in the art at the time of 
the invention to modify Wang by using UDP. 

On page 19 of the Remarks, Applicant points out that UDP is actually a connectionless 
protocol. The Examiner concedes this point. However, as noted in techdictionary.com, a 
socket is merely a destination address and port for exchanging data between computers. 
Therefore, UDP sockets are still inherently required in order to transmit data over the 
network. Indeed, Applicant's own claimed invention would not make sense if this were not 
the case (e.g. how could you claim UDP sockets if they did not exist?). 

Applicant's arguments regarding claims 1 1 and 12, found on pages 21-24 of the 
Remarks, are not persuasive for the same reasons cited above with respect to claim 1. In 
addition, on page 22, Applicant asserts that the references do not teach and that the Office 
Action does not allege to teach, "an interface device. . .including. . .a mechanism configured to 
associate said data with a User Datagram Protocol header corresponding to said User 
Datagram Protocol socket such that said data is communicated between the network and the 
peripheral device without encountering said host computer." The Examiner respectfully 
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disagrees. First of all, the previous Office Action clearly detailed that Wang teaches each 
limitation of the claim except for the use of UDP. Specifically, just such an interface device 
is clearly illustrated in Fig. 3 (network I/O device) and Fig. 5. Moreover, it is clear that the 
data transfer occurs directly between the storage device and the interface device without 
encountering said host computer (see col. 4, lines 55-57). The motivation for using UDP 
packets and headers (which inherently also includes UDP sockets) is provided by 
Schulzrinne, as further detailed in the previous Action and clarified above. 

Regarding claims 3-6 and 13-15, Applicant makes various arguments on pages 19-20 and 
24-25 of the Remarks, asserting that the references do not teach creating RTP headers, 
prepending the headers to the data, processing the UDP headers, or concatenating the data 
fragments (packets). To the contrary, the Examiner finds that all of these features are 
inherent to the use of RTP and UDP and, in fact, explicitly taught by Schulzrinne in the 
sections cited in the previous Office Action and repeated in the rejection above. In summary, 
RTP and UDP require the use of headers which are prepended to the packetized data. As 
understood by one of ordinary skill in the art, protocol stacks (see definition from 
techdictionary.com) located in the respective network interfaces process the headers in order 
to packetize (sending side) and concatenate (receiving side) the data packets. Once modified 
to use RTP/UDP, as motivated by Schulzrinne, the interface device of Wang would 
necessarily comprise just such a protocol stack for performing these functions. 

With respect to claims 13-15, Applicant requests that the Examiner point out where 
Schulzrinne teaches an "interface device." First, Schulzrinne is not required to explicitly 
teach using an interface device, because Wang teaches the use of an "interface device" 
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(network I/O device, Fig. 3). Second, even if Wang did not teach this feature, the use of an 
interface device is inherent to any system embodying the teachings of Schulzrinne for 
sending and receiving packets over a network, as would have been obvious to one of ordinary 
skill in the art. It is not possible to send and receive data packets on a network unless there 
are at least two interfaces devices for performing the respective sending and receiving. 

For all of these reasons, claims 3-6 and 24-25 are properly rejected as obvious over Wang 
in view of Schulzrinne. 

Applicant's arguments with respect to claim 2 are found on pages 26-27 of the Remarks. 
The grounds for the rejection have been clarified above and are further reiterated here. The 
Examiner finds that Wang explicitly teaches the use of application layer headers, which 
inherently includes prepending these headers to the data (col. 11, lines 14-36), because 
otherwise the data packets could not be transferred. It is not clear from Wang whether or not 
these application layer headers are created by the host computer or the interface device. 
AAPA (pg. 31, line 28 - pg. 32, line 8) teaches that it is conventionally known to generate an 
application packet header at a host computer. Therefore, it would have been obvious to one 
of ordinary skill in the art at the time of the invention to modify the teachings of Wang and 
Schulzrinne by configuring the host computer to create an application layer header that is 
accessible by said interface device in order to transmit data about the application over the 
network. Moreover, it would have been obvious to generate the application headers at the 
host computer of Wang, because the application resides on the host computer and this would 
simplify data processing. 
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For all of these reasons, claims 1-18, 20 and 21 are properly rejected under 35 U.S.C. 
103(a). 

Conclusion 

23. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure: 

Search results for "protocol stack," "cache," and "User Datagram Protocol" from 
techdictionary.com, visited 2/17/05; 

Sung, RFC 1791, http://www.ietf.org/rfc/rfcl791.txt?number=1791, April 1995. 

24. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until 
after the end of the THREE-MONTH shortened statutory period, then the shortened statutory 
period will expire on the date the advisory action is mailed, and any extension fee pursuant to 
37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

25. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Aaron C Perez-Daple whose telephone number is (571) 272- 
3974. The examiner can normally be reached on 9am-5pm. 
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If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Follansbee can be reached on (571) 272-3964. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published 
applications may be obtained from either Private PAIR or Public PAIR. Status information 
for unpublished applications is available through Private PAIR only. For more information 
about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access 
to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 
(toll-free). 
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